-
Notifications
You must be signed in to change notification settings - Fork 257
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(pyroscope): switch to in-memory profile handling for AppendIngest #2577
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would love to see a test covering the error condition here with the closed pipe.
I am a bit unsure that we actually need the Pipeset's atomic.bool
(I have not tried running code though).
My best guess is as io.MultiWrite
will fail on the first error and no longer continue. We would need to move out the Close to happen once all appenadables have read the body.
1a3d3ab
to
43e2818
Compare
@simonswine I've completely changed the approach after our discussion. Instead of managing pipes and their lifecycle (which required careful coordination of reads/writes/closes), we now:
This matches how Append() already handles profiles internally and eliminates all the complexity around pipe handling. The tests still verify the same functionality (including error cases) but the implementation is much simpler and more reliable. LMKWYT |
43e2818
to
8a4f9bb
Compare
8a4f9bb
to
6fac4a8
Compare
💻 Deploy preview available: https://deploy-preview-alloy-2577-zb444pucvq-vp.a.run.app/docs/alloy/latest/ |
6fac4a8
to
a0e3479
Compare
aea9afe
to
6d37eb8
Compare
3670c7f
to
bbf9c76
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Thanks for your work on that, this makes the whole thing a bit simpler.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM and cleaner.
Clayton shouldnt need to look at this since it only holds changelog.md |
Kicking off the drone build. which is concerning it doesnt block the merge. |
Do you mean to merge to marcsanmi/pyroscope-relabel-component? Is this a WIP? |
Yes, I had in mind merging it once this PR is approved and merged. I made it from that branch since I originally spotted the issue after introducing the relabel component, thus to fully test the fix I needed the new component. If it's a problem, I can create a new branch and cherry pick the commits. |
bbf9c76
to
afdef0e
Compare
afdef0e
to
277f86a
Compare
e89f475
to
c78f23b
Compare
c78f23b
to
da1d816
Compare
PR Description
Depends on #2574
Changes the profile handling in
receive_http
andwrite
components related to profiles received and write from/ingest
API instead of using pipes for fanout operations.This matches how
Append()
already handles profiles (as RawProfile) and simplifies the code by:The change affects:
Note: This approach means profiles are held in memory until all appendables finish processing.
This matches how Append() already handles profiles internally, which has proven reliable in production with no memory issues reported so far.
Which issue(s) this PR fixes:
Replaces the previous pipe-based approach that could lead to "read/write on
closed pipe" errors with a more robust in-memory solution.
Notes to the Reviewer
PR Checklist